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(54) Abstract Title 

Cell updates in a UMTS terrestrial radio access network 

(57) In a UMTS radio access network, a method of informtng a serving RNC, SRNC, of the FACH transport 
channel configuration allocated by a drift RNC (DRNC) 5 to user equipment (UE) 7. When the UE 7 first moves 
into a cell of the DRNC 5, forwarding an RRC Cell Update message from the DRNC 5 to the SRNC 4, sending a 
RNSAP Common Transport Channel Resource Request message from the SRNC 4 to the DRNC 5, and sending 
a RNSAP Common Transport Channel Resource Response message from the DRNC 5 to the SRNC 4, said 
response containing an information element indicating whether FACH flow control information contained in 
the response is unique to the DRNC cell to which the procedure relates, or whether the information is common 
to all of the cells of the DRNC. If said information element indicates that the information is common to all of 
the cells of the DRNC 5, the SRNC 4 does not perform the RNSAP Common Transport Channel Resources 
Initialisation procedure for subsequent Cell Update messages received from the DRNC 5. 
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Cell Updates in a UMTS Terrestrial Radio Access Network 
Pield of the Invention 

5 The present invention relates to the handling of cell updates at the lur interface of a 
UMTS Terrestrial Radio Access Network (UTRAN), the lur interface being the 
interface between Radio Network Controllers (RNCs) of the UTRAN. 



Backgroun d to the Invention 
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The European Teleconununications Standardisation Institute (ETSJO is currently in the 
process of standardising a new set of protocols for mobile telecommunications systems. 
The set of protocols is known collectively as the Universal Mobile Telecommunications 
System (UMTS). The architecture of a UMTS network is based upon a UMTS core 

15 network and a UMTS Tenrestrial Radio Access Network (UTRAN). The UTRAN 
comprises a number of Radio Network Controllers (RNCs). each of which is coupled to 
a set of nei^bouring Base Transceiver Stations (BTSs) or Node Bs. Each Node B is 
responsible fi>r a given geographical area or cell, and the controUmg RNC is responsible 
for routing user and signalling data between that Node B and tiie core network. The 

20 interface between an RNC and a Node B is referred to as the lu interface. A general 
outline of the UTRAN is given in Technical Specification TS 25.401 (UTRAN overall 
description) of the 3ni Generation Partnership Project, 3GPP. 

User and signalling data may be carried between an RNC and a mobUe terminal 
25 (refeired to in UTRAN as User Equipment (UE)) using Radio Bearers (RBs). 
Typically, a mobile terminal is allocated one or more RBs. each of which is capable of 
carrying a flow of user or signaUing data. At a Radio Link Control (RLC) entity, RBs 
are mapped onto respective logical channels. At a Media Access Control (MAC) entity, 
a set of logical channels is mapped in turn onto a transport chamiel, of which there are 
30 two types: a "common" transport channel which is shared by different mobile terminals 
and a "dedicated" transport channel which is allocated to a single mobile terminal. One 
type of common channel is a Forward Access CHannel (FACH). Several transport 
channels (e.g. FACHs) are in turn mapped at the physical layer onto a Secondary 



2 



Common Control Physical CHannel (S-CCPCH) for transmission over the air interface 
between a Node B and a mobile terminal 

When a mobile terminal registers with an RNC, via a Node B, that RNC acts at least 
5 initially as both the serving and controlling RNC for the mobile terminal. The RNC 
both controls the air interface radio resources and teiminates the layer 3 intelUgence 
(Radio Resource Control (RRC) protocol), routing data associated with the mobile 
terminal directly to and from the core network. Figure 1 illustrates the protocol model 
for the FACH transport channel when the serving and controlling RNCs are coincident 

10 and where Uu indicates the interface between the UTRAN and the mobile terminal 
(UE), and lub indicates the interface between the RNC and a Node B. It will be 
appreciated that the MAC (MAC-c) entity in the RNC transfers MAC-c Packet Data 
Units (PDUs) to the peer MAC-c entity at the mobile terminal, using the services of the 
FACH Frame Protocol (FACH FP) entity between the RNC and the Node B. The 

15 FACH FP entity adds header infomation to the MAC-c PDUs to form FACH FP PDUs 
which are transported to the NodeB over an AAL2 (or other transport mechanism) 
connection. An interworking function at the Node B interworks the FACH frame 
received by the FACH FP entity into the PHY entity. 

20 Consider now the situation which arises when a mobile terminal leaves the area covered 
by a RNC with which the temiinal is registered, and enters the area covered by a second 
RNC. Under the UTRAN protocols, the RRC remains terminated at the first RNC 
whilst the terminal takes advantage of a cell and conmion transport channel of the 
second RNC. Thus, the first RNC remains as the serving RNC with a connection to the 

25 core network whilst the second RNC becomes the controlling RNC. The controlling 
RNC is in control of the NodeB where the mobile terminal is located and in particular 
of the logic£il resources (transport channels) at that Node B. hi this scenario the 
controlling RNC is referred to as a "drift" RNC (the controlling RNC will also be acting 
as a serving RNC for mobile terminals registered with that RNC). The protocol model 

30 for the FACH transport channel when the serving and controlling RNCs are separate is 
illustrated in Figure 2. It will be noted that a new interface lur is exposed between the 
serving and the controlling RNCs. The RNSAP protocol is used for control plane 
signalling on the lur interface. 
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When a mobile tenninal first moves into the coverage area of the (new) DRNC, the 
mobile tenninal must send an RRC Cell Update message to the SRNC to inform the 
SRNC of its new location. The RRC Cell Update message (L3 information) is 

5 forwarded by the DRNC to the SRNC using the RNSAP UL Signalling Transfer 
message. Upon receipt of a Cell Update, the SRNC must determine the configuration 
(scheduling priority. MAC-c/sh SDU length(s), and initial window size) of the FACH 
transport channel used by the DRNC for the ceU to which the update relates. According 
to the current standard, the SRNC responds to receipt of a Cell Update by sending a 

10 RNSAP Common Transport Channel Resource Request message to the DRNC over the 
lur interface. The DRNC responds with a RNSAP Common Transport Channel 
Resource Response message containing the configuration information. 

In some network configurations, the FACH transport channel configuration may be the 
15 same for aU cells of an RNC. hi other network configurations, the configuration may 
differ from cell to cell. The cuirent standard handles this situation by performing the 
RNSAP procedure (request and response sequence) each time a CeU Update is received 
at the SRNC over the lur interface, i.e. for the first and subsequent cell updates. 

20 Summary of the Invention 

The approach adopted by the current standard has two main disadvantages. Firstly, the 
RNSAP exchange procedure introduces a delay into the cell update procedure. This 
may cause an interruption m the service provided to a mobile terminal and results in a 
25 less than optimal use of radio resources. Secondly, the procedure increases the 
signaUing load on the lur interface, hi conununications networks, a greater signalling 
load often results in higjira: mfirastructure costs. 

According to a first aspect of the present invention there is provided, in a UMTS radio 
30 access network, a method of informing a serving RNC, SRNC, of the FACH transport 
channel configuration allocated by a drift RNC. DRNC. to user equipment, UE, the 
method comprising: 
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including in a RNSAP message sent from the DRNC to the SRNC, an 
infomiation element indicating whether FACH flow control infomiation contained in 
the response is unique to the DRNC cell, or whether the information is common to all of 
the cells of the DRNC, 

5 wherein if said information element indicates that the information is common to 

all of the cells of the DRNC, the SRNC does not perform the RNSAP Common 
Transport Channel Resources Initialisation procedure, request/response sequence, for 
Cell Update messages subsequently received from the DRNC. 

10 In one embodiment of the invention, said RNSAP message is sent as part of a RNSAP 
Common Transport Channel Resources Initialisation procedure between the SRNC and 
the DRNC. 

Only in the event that the RNSAP Common Transport Channel Resource Response 
15 message indicates that the FACH flow control information is not common to all cells 
will the RNSAP Common Transport Channel Resources Initialisation procedure be 
repeated for subsequent cell updates corresponding to movement of the UE between two 
cells of the DRNC. Embodiments of the present invention both speed up the cell update 
procedure when a DRNC is involved and reduce the volume of signalling traffic over 
20 the lur interface. 

In one embodiment of the present invention, the RNSAP procedure is performed when 
the UE first moves into a cell of the DRNC and following the forwarding of an RRC 
Cell Update message from the DRNC to the SRNC using the RNSAP Uplink Signalling 
25 Transfer procedure, the procedure comprising sending a RNSAP Common Transport 
Channel Resource Request message from the SRNC to the DRNC, and sending a 
RNSAP Common Transport Channel Resource Response message from the DRNC to 
the SRNC, one of said Cell Update message and said response containing said 
information element. 

30 

Brief Description of the Drawings 
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5 

Figure 1 illustrates a protocol model for a FACH transport channel when serving and 
controlling KNCs of theUTRAN are coincident; 

Figure 2 illustrates a protocol model for a FACH transport channel when serving and 

controlling RNCs of the UTRAN are sqwrate; 

Figure 3 iUustrates schematically a part of a UMTS network; 

Figure 4 is a flow diagram illustrating a method of handling cell updates via lur in the 
UMTS network of Figure 3; and 

Figure 5 illustrates the flow of signalling inforaiation related to a cell update between a 
DRNCandaSRNC. 

Detailed Description of a Preferred Embodiment 



Protocol models for the FACH transport channel of a UMTS network have been 
described with reference to Figures 1 and 2 for the cases where the serving RNC and 

15 controlling RNC are both coincident and separate. Figure 3 illustrates a part of a UMTS 
network comprising a core network 1 and a UMTS terrestrial radio access network 
(UTRAN) 2. Shown in the XJTRAN 2 are a pair of Radio Network Controllers (RNCs) 
4,5. each of which has control of a set of Node Bs 6. Bach Node B 6 provides radio 
coverage of a particular geographic cell, with the cells of neighbouring Node Bs 

20 overlaiqping. 

In the scenario iUustrated in Figure 3, a UE 7 is shown communicating with one of the 
Node Bs of a first of the RNCs 4. The UB is assumed to move fcom the coverage area 
of the Node B of the first RNC 4 into the coverage area of a Node B of the second RNC 

25 5. The effect of the UE 7 roaming in this way is to cause the UE to take advantage of 
common transport channels (RACH/FACH) of the second RNC 5. the drift RNC 
(DRNC). As described above, the RRC protocol remains terminated at the first RNC, 
the serving RNC (SRNQ. The UE 7 will send an RRC Cell Update message to the 
SRNC 4 to inform the SRNC of its new location. This message is sent via the DRNC 5 

30 across the lub and lur interfaces (and is the first connection between the UE and the 
DRNC). 
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The Cell Update message contains the U-RNTI (SRNC Id + RNTI (Radio Network 
Temporary Identity)) which identifies the UE within UTRAN. At reception of the Cell 
Update message, the DRNC checks the U-RNTI. As the UE is not registered in the 
DRNC, the DRNC forwards the Cell Update message, using the RNSAP UpUnk 
5 Signalling Transfer message, to the SRNC based on the SRNC Id in the U-RNTI. 

When the SRNC 4 receives the first Cell Update message fi-om the DRNC, the SRNC 4 
updates its cell location register, and initiates the RNSAP Common Transport Channel 
Resources Initialisation procedure. This involves the sending of a RNSAP Common 
10 Transport Channel Resource Request to the DRNC. This message is a request to 
establish the user plane towards the DRNC 5 and for the DRNC to return to the SRNC 4 
the FACH transport channel configuration for the cell in which the UE 7 is now located. 
As already stated above this configuration information includes the scheduling priority, 
MAC-c/sh SDU length(s), and initial window size. 

15 

The DRNC 5 responds to receipt of the RNSAP request message by generating and 
returning to the SRNC 4 a RNSAP Common Transport Chaimel Resource Response. 
This message has the following structure: 



IE/Group Name 


Presence 
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IE type and 
reference 


Semantics 
description 


Criticality 


Assigned 
Criticality 


Message Type 


M 
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S-RNTI 


M 
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ignore 
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O 
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>FACH Flow Contiol 
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ignore 


Transport Layer Address 


O 
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ignore 


Binding Identity 


O 
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YES 


ignore 


Criticality Diagnostics 


O 




9.2.1.13 




YES 


ignore 



20 

where the presence field indicates whether or not the information elements of the 
message are mandatory (M) or optional (O). 

The RNSAP response message includes an additional information element (IE) referred 
25 to as "Cell Unique FACH Flow Control Info'*. This element contains a flag which can 
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be set to yes to indicate that the FACH transport channel configurations for all of the 
cells of the DRNC 5 are the same, or no to indicate that the configuration differs from 
cell to cell. The fiag is set by the DRNC 5. It is noted that whilst in the above table, the 
additional IE is indicated as being mandatory, this need not be so and it may be included 
5 as an optional feature. 

When the RNSAP response is received by the SRNC 4, the Cell Unique FACH Flow 
Control Info IE is analysed. If the IE is set to yes, the SRNC 4 records the fact that it 
must execute the RNSAP Common Transport Channel Resource InitiaHsation procedure 
10 for every subsequent cell update in the DRNC 5. If the IE is set to no, the SRNC 4 
records the feet that the procedure is not needed for subsequent ceU updates within the 
DRNC 5. 

Figure 4 is a flow diagram fiirther illustrating the method described above. Figure 5 
15 illustrates the flow of signalling information ova- the lurinterfece. 

It will be appreciated by the person of skUl in the art that various modifications may be 
made to the above described embodiments without departing fiom the scope of the 
present invention. For example, it is possiTile that a connection between the UE and the 

20 DRNC may exist prior to the first ceU update. If the UE is using dedicated channels 
(DCHs) via ttie DRNC, the SRNC may decide to perform a channel switch fix>m DCH 
to FACH (e.g. if the UE has only a best effort packet data RAB and the traffic activity is 
low). In this case flie SRNC may: a) select the target ceU for the UE when switching to 
FACH; or b) force'the UE to perform a ceU update (in this case the target cell is selected 

25 by the UE) before switching to FACH. Hie SRNC indicates in RRC signalling to the 
UE whether the UE shall use a cell selected by the SRNC (alternative a) or perform a 
ceU iq>date (alternative b). In alternative a, the SRNC will perform the RNSAP 
Common Transport Channel Resource Initiation procedure without first having received 
a cell update from the UB via the DRNC. In alternative b, the RNSAP Common 

30 Transport Channel Resource Initialisation procedure follows a cell update. 
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Claims 

1 . In a UMTS radio access network, a method of informing a serving RNC, SRNC, 
of the FACH transport channel configuration allocated by a drift RNC, DRNC, to user 
5 equipment, UE, the method comprising: 

mcluding in a RNSAP message sent from the DRNC to the SRNC, an 
infomiation element indicating whether FACH flow control information contained in 
the response is imique to the DRNC cell, or whether the information is common to all of 
the cells of the DRNC, 

10 wherein if said information element indicates that the information is common to 

all of the cells of the DRNC, the SRNC does not perform the RNSAP Common 
Transport Channel Resources Initialisation procedure, request/response sequence, for 
Cell Update messages subsequently received from the DRNC. 

15 2. A method according to claim 1, wherem said RNSAP message is sent as part of 
a RNSAP Common Transport Channel Resources Initialisation procedure between the 
SRNC and the DRNC. 

3. A method according to claim 2 and comprising performing the RNSAP 
20 procedure when the UE first moves into a cell of the DRNC and following the 

forwarding of an RRC Cell Update message from the DRNC to the SRNC using the 
RNSAP Uplink Signalling Transfer procedure, the procedure comprising sending a 
RNSAP Common Transport Channel Resource Request message firom the SRNC to the 
DRNC, and sending a RNSAP Conmion Transport Channel Resource Response 
25 message from the DRNC to the SRNC, one of said Cell Update message and said 
response containing said information element. 

4. A method according to claim 1, wherein said RNSAP procedure is carried out as 
part of a channel switch, &om a DCH to a FACH. 

30 

5. A method according to claim 1, wherein said RNSAP procedure follows receipt 
of a ceU update message from the UE at the SRNC. 



A Radio Network Controller for use in a UTRAN and comprising processing 
jfor implementing the me&od of any one of the preceding claims. 
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